The present disclosure relates generally to a method of integrating case based reasoning data and failure modes, effects and criticality analysis (FMECA) data. In particular, the present disclosure relates to a method of correlating data contained in a case based database and data contained in a FMECA database in order to allow case based reasoning data to be accessed via the FMECA database.
Failure modes and effects analysis (FMEA) is a methodology for determining the root causes and suggested corrective actions for defects in manufacturing processes and products. FMEA can be applied during the design phase of a product or process to identify potential fault modes or defects that may cause product or process failures. The FMEA methodology emphasizes defect prevention by examining all potential causes of a defect; the likelihood of these causes occurring and resulting in the defect; and ways of preventing these causes from occurring and resulting in the defect. The causes of defects in products may be defects in components that may be caused by sub-component defects. A typical FMEA includes a hierarchical list by component type of what happens to the overall product and the component when each part of the product fails. The hierarchy can include levels such as major division, system, sub-system, assembly, sub-assembly and part. The risk of potential fault modes are prioritized based on an estimated frequency of detection and severity. The probability of certain defects may be estimated by applying statistics to product or process histories. Otherwise, probabilities may be estimated based on experience.
Typically, in product or process design, an individual or a team is assigned to create a FMEA report or document. Team members can include representatives from disciplines such as engineering, purchasing, finance and field service. Performing FMEA can require that several experts assemble in one location for significant periods of time to generate the FMEA data. In a series of meetings, team members apply their expert knowledge and experience to develop a list of potential defects, their effects (e.g., severity), and potential causes of the defects. In addition, the defects are prioritized according to an estimated risk. The work is often divided up among the team members to be performed outside the meeting. The work performed outside the meeting is then discussed and validated in the meetings. The team comes to consensus on whether each potential defect and the effects and causes of the defect are correct, and how much risk there is for each. After the meetings have concluded, the resulting consensus information is gathered into a FMEA report or document. A typical FMEA report can contain hundreds of entries.
The FMEA team can also document suggested corrective actions to prevent the defects or faults from occurring during customer use of the product or process. This data can be added to the FMEA report. This augmentation of the FMEA report with corrective action data for fault modes is referred to as a failure modes, effects and criticality analysis (FMECA) report. Once the product or process is released for customer use, a case based system is typically utilized to track and resolve actual product or process failures in the field.
In contrast to FMECA, that includes a list of possible failures, a case based system tracks actual field failures. Problem-solution case bases are collected by service call centers and field service reporting methods. The case based data can be a collection of files or database objects that include large volumes of text descriptions. Cases can be classified based on variables such as date, customer, type of equipment, problem and solution. The data included in a FMECA report or database (e.g., potential failures) is often inconsistent in content and format with the data stored in a case based system (e.g., actual failures).